home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
noop
/
noop-minutes-92mar.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
17KB
|
440 lines
CURRENT_MEETING_REPORT_
Reported by Sue Hares/Merit, David Bolen/ANS and Dave Miller/MITRE
Minutes of the Network OSI Operations Working Group (NOOP)
The Network OSI Operations Group met three times during the week of the
San Diego IETF. The first meeting took place on Monday morning. Steve
Deering presented his ideas behind his paper ``City Codes is an
Alternative to Topological NSAP Allocation (RFC 1237).'' In addition,
Ross Callon presented the basics of RFC 1237. Both presentations
prompted a great deal of discussion. Sally Tarquinio took very detailed
notes of the discussion. Due to the length of both the notes and the
discussion, the notes will not be available in the Proceedings. Notes
may be retrieved via anonymous ftp from merit.edu in
/pub/iso/noop/notes/notes.03.16.92.am).
In addition to the City Code discussion, the following topics were
discussed:
o Mobile Hosts
o Comparison Geographical Area Code (GARP) with NAT and CNAT
o GARP vs RFC 1237
o Whether asymmetric pathways are acceptable.
The second NOOP session occurred on Wednesday morning at 9:00 a.m. and
covered several different items. Notes were taken by David Bolen.
Usage Questionnaire
Sue Hares made available copies of the OSI usage questionnaire and
requested that anyone involved with OSI work try to complete one. This
was a copy of the same questionnaire that was previously distributed
electronically.
A question was raised as to why DECnet was considered different than
CLNP (p. 9) - the answer was that it wasn't really, but the goal was to
see if DECnet usage was pushing CLNP usage (here, DECnet really means
DECnet Phase V traffic).
NEARnet OSI Routing/Addressing Plan
o Introduction
John Curran from NEARnet (New England Academic & Research Network)
made a presentation of NEARnet's OSI Plan. NEARnet is comprised of
120 members in six states, and coordinates with other New England
service providers to provide service in that area. Cisco routers
are used throughout NEARnets network.
1
o Address Assignment Plan
When researching an address assignment plan, NEARnet found that
area codes were a nice match for population density, and therefore
for assignment beneath NEARnet's AAI.
NEARnets final address format breakdown assumed the following
limits:
- Total of 16 COs per area code.
- Total of 256 RDs per CO. This could be a real problem in a
fairly short-term (~ two years). It is hard to gauge demand
though, and NEARnet isn't the only network assigning in the New
England area.
CO codes are assigned to aggregate at other boundaries as well:
.00-.3F = Massachusetts (.10 = 508 area code, .20 = 617, etc..)
.40-.4F \
.50-.5F \ Assign to different states - allows room for
.60-.6F / expansion according to area code.
.70-.7F /
.80- still some slack available for future expansion
The next step is then to assign RDs logically under this scheme.
The multiple aggregation points within this scheme helps to limit
the routing table size.
o Routing (ala RFC1237)
The following points were raised with respect to routing issues
under this sort of an address assignment scheme:
- Routes will often have to be manually injected.
- IGRP is not currently collapsing routes - hopefully newer
protocols will begin to do this.
- NEARnet doesn't like the fact that they have to accept all
routes as it allows NEARnet's routing tables to grow without
bounds.
- NEARnet sees NSAP changes as a lot of work currently - thus, if
a customer has already been assigned an RD, NEARnet lets the
customer keep it.
- NEARnet will accept any other assignments, but isn't sure what
will happen with other networks - will they be as accepting as
NEARnet?
o Questions
John brought up the general question as to what the general opinion
of this plan was. Could the approach be viewed as dangerous? The
following points were raised:
2
- Something has to be done, and at least this policy allows
future aggregation - it's very hard to take back what we give
out today.
- There could be a problem if all service providers don't become
as accepting as NEARnet. If routes begin to be refused, it
might cause everyone to bail out to their own AAI which would
create a flat address space once again.
- If we are allowing entropy at all (as this plan does), then
there needs to be some sort of entropy reduction in the system.
A possible recourse might be the need to start charging for the
announcement of a special route to other networks.
A general point was made that at the moment, the whole area of
addresses and assignment represents more of a controlled economy
than a true market economy. Moving from one to the other is always
tough.
NEARnet's addressing and routing plan may be found (via anonymous
ftp) in:
nic.near.net:/docs/osi-routing-plan.txt or
merit.edu:/pub/iso/noop/papers/nearnet.osi-routing-plan.txt
John also gave credit to CICNet for their previously released OSI
plan, and said that NEARnet's plan borrowed a lot from CICNet's.
OSI Pilot Projects
The discussion of OSI pilot projects centered around some documentation
that Sue supplied describing some of the work that RARE is doing in this
area. RARE has a suite of tests that they are requesting users at their
sites to perform, sending them results back to a central site to be
summarized. Sue was interested in whether or not their was enough
interest in trying the same sort of pilot plan here in the U.S., as well
as trying to get together another OSI demo for Interop East.
The general consensus of the Group was that, yes, it would be useful to
try the same sort of pilot project here, and that the RARE approach
seemed a reasonable way to proceed. It would also be nice to see about
some coordination with RARE, although mostly for inter-domain and
application level than at the ES-IS and IS-IS level. The
application-level portion of the RARE plan was a little weak, and may
need to be augmented for our tests.
A possible problem was brought up in that a number of sites have beta
implementations of OSI code, and may not be able to publish the results
of tests. Sue suggested that at least saying ``I've tested'' is useful,
even if the exact results of the test cannot be released.
NIST was brought up as an organization that was already handling some
OSI testing in the same vein as what was being discussed. NIST has
provided open labs and a test environment for multiple vendors to come
together in order to test interoperability. There has been no automated
3
or documented test procedures followed, however - just vendor engineers
running particular tests. Richard Collela will be sending some further
information about this testing to the NOOP mailing list.
The fundamental difference between the testing that has been performed
at NIST, and the type of pilot projects being run by RARE is that the
latter case involves actual end users, while the former is run by the
vendors and their engineers.
John Curran suggested that the request for tests be sent out to the NOOP
list. While many midlevels may not run the tests themselves, they may
have clients that can. Sue Hares agreed to send the test plan, and a
request for volunteers to the NOOP mailing list.
Document Review: (reported by Dave Miller)
o TOOLS RFC
Their was a brief discussion on the ``Tools'' Document and the need
for tools to provide OSI ping, OSI traceroute, and OSI routing
table dump utilities. The discussion then focused on what routing
table information should be available via SNMP. It was noted that
the document should specify a minimal set of objects as MUST
requirements for this specification.
For CLNS MIB objects, no one took exception to the list in the
draft document. For IS-IS, the document currently states the
object in very general terms. Dino Farinacci was asked to write-up
a minimal list of IS-IS objects and send them to the NOOP mailing
list. For IDRP, no one took exception to the list in the draft
document.
There was no review of objects for CMIP management at this time.
o SURVEY FORM
Sue Hares gave a status overview of the OSI in the Internet Survey.
The plan to maintain the survey is to perform a monthly revision to
incorporate any new information received. Sue also encouraged
others to respond to the survey since only about ten responses have
been received to date.
There were a few suggestions to modify the survey (it was noted
that the changes should be highlighted when new surveys are sent
out):
- DECnet traffic should refer to DECnet Phase V traffic.
- Text should refer to RFC 1006 as opposed to a TCP/IP stack.
- There should be a context section added to identify who's
responding to the survey and what their role in OSI is.
Cathy Wittbrodt suggested that the surveys be stored individually
on-line so particular responses could be retrieved as desired. Sue
agreed to do this.
4
Dave Farber suggested sending the survey out to the IETF mailing
list to reach a broader community. Sue agreed to do this.
o SECURITY RFC
Walt Lazear gave an overview of the OSI Packet Filtering document.
The document discusses the issues associated with filtering OSI by
application type in the context of using packet filtering to
restrict OSI connections (establishing firewalls).
Walt noted that he has not received comments on the current
document and solicited feedback.
There was some discussion of what were the security requirements
that were trying to be met. MITRE was asked if they could put
together a short paper on OSI security policy to set the context
for this work and to stimulate further discussion. Bill Barns
volunteered himself and Walt to pursue this.
o NIST IS-IS TEST LAB
Rich Colella gave a quick overview of the IS-IS test lab
established at NIST. Two Open Lab sessions have been conducted to
date to perform vendor interoperability testing.
A report of the router testing is being prepared. Rich agreed to
get a copy of the completed report sent to the NOOP list.
The third NOOP sessions took place during the 7:00 p.m. session on
Wednesday, March 18th, and was devoted to discussion of the IDRP for IP
document. A new working group will be formed to discuss the IDRP
issues. Detailed notes are available via ftp, cd ietf, get
noop-minutes-92mar.txt).
NOTES>>>>>>>
IDRP for IP
IDRP can be found in merit.edu:/pub/iso/idrp.ps IDRP for IP will be
submitted as an Internet Draft by April 1st.
1. BISPDU (IDRP packet) in IP packet with unique protocol ID.
IDRP provides a reliable transport so TCP not needed.
2. IP addresses encoded in NLRI and NET.
Current ANSI ballot proposal will allow direct encoding. This
ballot proposal will be a correction on the current DIS ballot
text.
3. IDRP for IP only has:
o No CLNP forwarding
o No IDRP GMDO for CMIP: (MIB will be part of an Internet
standard. Internet is using SNMP over CLTS.)
5
4. Minimal Configuration Information needed for IDRP.
o Intra-Domain ISs (routers)
o Location and identity of BIS (Border routers) in Domain
o IP addresses for Routing Domain (bag of networks)
o Routing Domain Identifier (RDI)
(New style AS)
47:0005:81:aa:aa
Where if AS number needs to be expanded, the aa:aa field can go
to 4 bytes.
o Rib Attribute Set = null
Rib Attributes identify QOS. QOS will be examined in a separate
document.
o Routing Domain Confederations - RDCs
Routing Domain Confederations this node is a part of.
o SNPAs of this node
5. IDRP compared to BGP-4.
Additional Features
o DIST_LIST_INCL, DIST_LIST_EXCL
DIST_LIST_INCL indicates which routing domains a set of routing
information may be passed to. DIST_LIST_EXCL states this
routing information may be passed to all RDs but the ones
listed.
o Local Preference (may be added to BGP-4)
o MULT_EXIT_DISC (may be added to BGP-4)
o RDC
o RD Sets
o IDRP has its own transport
o Hierarchical Recording
6. IDRP Deployment.
o Minimum configuration: 1 BIS, 1 BIS can pass to intra-domain
routing.
o IP Prefix goes in 1 Routing domain, not multiple.
Prefix is really 1 campus or RD, not the large ``bags'' of
networks that make up AS now.
Attendees
Andy Adams ala@merit.edu
Vikas Aggarwal aggarwal@jvnc.net
6
Robert Aiken raiken@nsf.gov
Steve Alexander stevea@i88.isc.com
Nagaraj Arunkumar nak@3com.com
Zorica Avramovic zorica@sparta.com
William Barns barns@gateway.mitre.org
Tony Bates tony@ean-relay.ac.uk
William Biagi bbiagi@cos.com
David Bolen db3l@nis.ans.net
Scott Brim swb@cornell.edu
J. Nevil Brownlee nevil@aukuni.ac.uz
Eric Brunner brunner@practic.com
Niels Brunsgaard nob@dowtyns.dk
Ross Callon callon@bigfut.enet.dec.com
John Chang jrc@uswest.com
A. Lyman Chapin lyman@bbn.com
Henry Clark henryc@oar.net
Alan Clegg abc@concert.net
Richard Colella colella@osi.ncsl.nist.gov
Rob Coltun rcoltun@ni.umd.edu
Robert Cooney cooney@wnyose.nctsw.navy.mil
Curtis Cox ccox@wnyose.nctsw.navy.mil
Dave Cullerot cullerot@ctron.com
John Curran jcurran@bbn.com
Steve Deering deering@xerox.com
Kathleen Dodd kathy@gateway.mitre.org
Tom Easterday tom@cic.net
Dino Farinacci dino@cisco.com
Stefan Fassbender stf@easi.net
Peter Ford peter@lanl.gov
Karen Frisa karen.frisa@andrew.cmu.edu
Vince Fuller vaf@stanford.edu
Eugene Geer ewg@nvuxr.bellcore.com
Robert Hagens hagens@cs.wisc.edu
Susan Hares skh@merit.edu
Jeff Hayward j.hayward@utexas.edu
Juha Heinanen juha.heinanen@datanet.tele.fi
Randy Hoebelheinrich rho@rowan.lanl.gov
Kathleen Huber khuber@bbn.com
Bob Jeckell rrj@3com.com
Barbara Jennings bjjenni@sandia.gov
Dan Jordt danj@nwnet.net
Dave Katz dkatz@merit.edu
H. A. Kippenhan kippenhan@fndcd.fnal.gov
Yoav Kluger ykluger@fibhaifa.com
Deidre Kostick dck2@sabre.bellcore.com
Eva Kuiper eva@hpindda.cup.hp.com
John Larson jlarson@parc.xerox.com
Walter Lazear lazear@gateway.mitre.org
Eliot Lear lear@sgi.com
Kurt Lidl lidl@sura.net
Susan Lin suelin@ibm.com
Tony Li tli@cisco.com
Triet Lu trietl@sparta.com
Gary Malkin gmalkin@xylogics.com
7
Bill Manning bmanning@rice.edu
Glenn McGregor ghm@merit.edu
Milo Medin medin@nsipo.nasa.gov
David Miller dtm@mitre.org
Henry Miller henrym@sacusr.mp.usbr.gov
Greg Minshall minshall@wc.novell.com
Dennis Morris morrisd@imo-uvax.dca.mil
Donald Morris morris@ucar.edu
Brad Passwaters bjp@sura.net
David Piscitello dave@sabre.bellcore.com
Jon Postel postel@isi.edu
Rex Pugh pugh@hprnd.rose.hp.com
Yakov Rekhter yakov@watson.ibm.com
Ron Roberts roberts@jessica.stanford.edu
Jonathan Rodin rodin@ftp.com
Benny Rodrig 4373580@mcimail.com
Manoel Rodrigues manoel.rodrigues@att.com
Sharad Sanghi sharad@ans.net
Erik Sherk sherk@sura.net
William Simpson Bill_Simpson@um.cc.umich.edu
Keith Sklower sklower@cs.berkeley.edu
Mark Sleeper mws@sparta.com
Frank Solensky solensky@clearpoint.com
Walter Stickle wls@ftp.com
William Streilein bstreile@wellfleet.com
Sally Tarquinio sally@gateway.mitre.org
Richard Thomsen rgt@lanl.gov
Claudio Topolcic topolcic@nri.reston.va.us
Paul Traina pst@cisco.com
Kannan Varadhan kannan@oar.net
Huyen Vu vi@polaris.dca.mil
Carol Ward cward@westnet.net
Bert Wijnen wijnen@vnet.ibm.com
Steve Willens steve@livingston.com
Scott Williamson scottw@nic.ddn.mil
Walter Wimer walter.wimer@andrew.cmu.edu
Linda Winkler lwinkler@anl.gov
Cathy Wittbrodt cjw@nersc.gov
Peter Yee yee@ames.arc.nasa.gov
8